If RFC6455 semantics are to be preserved the only way that it makes sense to do that is in a fully tunneled method such that the resulting stream could be fed to an existing RFC6455 infrastructure. While conceptually simple, as mentioned a number of times in the past threads, this introduces a number of problems including significant overhead and reduced transparency to HTTP 2.0 intermediaries. I don’t see any great benefit in this method.

I also don’t see any benefit in doing a half and half style protocol where RFC6455 frames are encapsulated in HTTP 2.0 header+data frame pairs. This seems like the worst of both worlds. Not enough like RFC6455 to actually re-use existing infrastructure but enough like it to make the messaging component not mesh well with the rest of HTTP 2.0. The alternate method proposed earlier where HTTP 2.0 simply defines its own “ordered bidirectional message stream” semantics independently of RFC6455 either via a specific frame type or via additional flags on the data frame seems to be an obvious choice to me.

HTTP 2.0 natively provides all of the core facilities that RFC6455 does: connection establishment, header flags, control messaging, close messaging, framing, etc. There is no need to redefine any of this in terms of RFC6455 opcodes or frame bits order to exchange messages bidirectionally over the existing connection between an HTTP 2.0 browser and server. Doing so only adds complexity for no real benefit. At best I can see including a method for mapping RFC6455 close codes to RST_STREAM error codes.

Using HTTP 2.0 for this sort of messaging would be less efficient than raw RFC6455 but likely more efficient overall for sites with a healthy mix of HTTP and WebSocket traffic to the same host. It would also solve any issues about unknown frame boundaries, make all messaging traffic a first class HTTP 2.0 citizen and understandable to intermediaries. It would not require HTTP 2.0 only programs to also have an RFC6455 parser. It would remove the need to try and fit any extensions designed for RFC6455 into HTTP 2.0 or restrict RFC6455 extension design to things that could fit into HTTP 2.0. There doesn’t seem to be anything supported by the JavaScript WebSocket API that couldn’t be easily transported using such a scheme.

That said, because of the differences between HTTP 2.0 and RFC6455 WebSockets I would hope to see them coexist in browsers rather than be a replacement. There are a number of cases that users of my WebSocket library have discussed with me where HTTP 2.0 is vast overkill and needlessly complex for what they need and RFC6455 fits the bill perfectly.

On the subject of WS MUX, given the existence of a protocol like HTTP 2.0 with the above messaging feature, based on the experiences of my library users and clients, any use case for a muxed WebSocket-type messaging system would be satisfied by HTTP 2.0.


On Jan 15, 2014, at 1:41, Takeshi Yoshino <tyoshino@google.com> wrote:

> On Wed, Jan 15, 2014 at 4:07 PM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:
> >>>In any layering scheme, we'd need to use a HEADER frame one way or another because we need to at least announce that we're connecting to a WS endpoint.
> 
> >>No, the alternative WS/SPDY proposal uses SPDY HEADER only for the initial WS opening handshake, but not for the subsequent WS messaging traffic.
> 
> >I think Roberto meant that we need to have code to parse HEADERS frame regardless of how layering scheme is. As you say, we'll exchange opening handshake using HEADERS. I.e. a server implementing your proposal will have HEADERS parser. So, use of HEADERS >itself doesn't add cost.
> 
> Yes, SPDY HEADER parsing code needs to be there in both, but:
> 
> The implementation cost for the current WS/SPDY proposal is for WS implementations that want to both support native WS and WS/SPDY:
> 
> the WS message data processing code needs to be intermingled with SPDY code.
> 
> With the alternative proposal (after the WS opening handshake is finished), the WS code can stay essentially untouched: the bytes just not come from wire anymore, but from SPDY data frame payloads.
> 
> Right. Inter-layer coordination complicates things given one has already implemented RFC6455. I understand your argument about clear layering.
> 
> It seems that there're different visions of how future transport for WebSocket API should be. IIUC, Roberto is trying to make HTTP/2.0 versatile transport for the web. He's thinking it's costly to carry over RFC6455 to that future. In Google, as you know, we're deploying SPDY widely and therefore SPDY is always there. If HTTP/2.0 is success, it'll be true also for others.
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi